Secure terminal provided with a smart card reader designed to communicate with a server via an internet network

ABSTRACT

The invention concerns an architecture of a terminal ( 5 ) allowing communications between a smart card ( 8 ) and a web server ( 4 ), via an internet network (RI). The terminal ( 5 ) is equipped with a secure enclosure ( 6 ) comprising a smart card reader ( 8 ), a keyboard ( 62 ), and optionally, other computing resources ( 63 ). The non-secure part of the terminal ( 5 ) comprises a web browser ( 51 ) and a first communication node ( 50 ) that routes the requests received to the browser ( 51 ) or to the secure enclosure ( 6 ). The secure enclosure ( 6 ) comprises a second communication node ( 60 ) and an HTTP server ( 61 ). The smart card ( 8 ) comprises a third communication node ( 80 ) and an HTTP server ( 81 ). The web server ( 4 ) comprises a merchant application ( 41 ) that can be placed in communication with the smart card ( 8 ) and activate software applications (A 1 –A n ) of the latter.

FIELD OF THE INVENTION

The invention relates to an architecture of a terminal, morespecifically a terminal of the type using a keyboard and a smart cardreader located in a secure enclosure, and designed to communicate with aserver via an internet network.

BACKGROUND OF THE INVENTION

A device of this type is known, for example, by the trade name“safepad.”

In the context of the invention, the term “terminal” should beunderstood in a general sense. The aforementioned terminal canspecifically be constituted by a personal computer running on variousoperating systems, such as WINDOWS or UNIX (both of which are registeredtrademarks). It can also be constituted by a workstation, a portablecomputer or a so-called dedicated card terminal.

Likewise, in the context of the invention, the term “internet network”includes, in addition to the Internet per se, private enterprisenetworks or the like, known as “intranets,” and the networks that extendthem to the outside, known as “extranets.”

Smart cards are used in various fields: banking and health careapplications, as so-called electronic “purses,” etc. Moreover, severalapplications can coexist in a smart card (a multi-application smartcard).

For these types of applications, smart cards can be assigned variousfunctions. In particular, they can be used for security purposes. Theterm “security” should be understood in a general sense, includingconfidentiality and/or the authentication of the user of the stationand/or the holder of the smart card itself.

In the more specific context of these applications, the terminal can beequipped with a secure enclosure comprising a smart card reader, akeyboard and possibly one or more other computing resources.

FIG. 1 schematically illustrates the architecture of a terminal of theaforementioned type, according to the prior art.

To illustrate the concepts, it is assumed that the terminal 1 isbasically constituted by a microcomputer. It is equipped with all theusual devices constituting such computing equipment and required fortheir proper operation (which are not represented): central processor,RAM, mass storage (hard disk), reader(s) information media (diskettes,etc.). In the particular case illustrated in FIG. 1, the terminal 1 isequipped with a secure enclosure 3 comprising a smart card 2 reader 30and a keyboard 31. The keyboard 31 is specifically used to enter datafor authenticating the holder of the smart card 2: for example apassword associated with an identifier of the smart card 2. Variouselectronic circuits allow communication between the secure elementspresent inside this enclosure, including the keyboard 31 and the smartcard 2 (via the reader 30), and between these secure elements and thenon-secure elements present in the terminal 1.

Normally, the terminal comprises, in its non-secure part, a specificapplication 10, which will be hereinafter be called a “merchant”application, which handles the management and control of specifictransactions permitted by the terminal 1 in question. Communicationsbetween this application 10 and the elements inside the secure enclosure3 normally take place in accordance with a standard of the RS232 type.Communications between the elements inside the secure enclosure 3,including a resident application 300, and the smart card 2, via thereader 3, normally take place in accordance with a protocol thatcomplies with the ISO standards 7816-1 through 7816-4.

This type of architecture specifically has the following primarydrawbacks:

the merchant application installed in the terminal (non-secure part) andthat residing in the secure enclosure are specific to this terminal;

the associated computer programs are generally voluminous; and

flexibility and reliability are limited, since any modification of theseprograms requires a reloading of programs into the terminal (non-securepart) and into the secure enclosure, and thus possibly the execution offunctional tests, which requires the presence of specialized personnel.

Generally, the latter operation must be repeated for a large number ofterminals.

It must also be kept in mind that these applications must be fully orpartially secure. It is therefore necessary to be able to guarantee, forthe updating of the programs, a given level of security, appropriate forthe specific application.

Most often, the terminal 1 is not isolated, in the sense that it islinked via a transmission network RI to one or more remote systems, oneof which 4 is illustrated in FIG. 1. The nature of the network RI canvary, depending on the applications envisaged (banking, health care,etc.). It could be the Internet or a network of that type (intranet orextranet), given the rapid growth of the latter type of network and theapplications that use it. Normally, the overall architecture is of theso-called “client-server” type, the “server” generally being the remotesystem 4 and the “client” being the terminal 1. But under certaincircumstances, the roles may be reversed or alternated during the timeof a transaction.

In an architecture of this type, the programs associated with thespecific application 10 and the application 300, during a modificationof their version for any reason whatsoever, can be updated in acentralized way, from one of the remote servers, for example the server4. It follows that one of the drawbacks indicated can be alleviated, theupdate being performed by downloading. These operations, however,require the implementation of administrative procedures that are wellknown. Moreover, the download can include sensitive data, or at leastshould not allow the installation into the terminal of programs and/orprocedures that are unauthorized or dangerous for security (a “Trojanhorse,” “logical bombs,” viruses, etc.).

Furthermore, with the increase in power and the universality of theInternet, there is a need to make the aforementioned specificapplications, installed locally in the terminals, “migrate” to theremote servers, which will hereinafter be called “merchant servers,” andto dialog directly with the smart card from these merchant servers.

This second need, in particular, cannot be satisfied by the terminals ofthe prior art, for reasons that will be explained below.

But first, it seems useful to briefly describe a system architecturethat allows communication between a terminal according to the prior artand a remote server, via an internet network RI. An architecture of thistype is represented schematically in FIG. 2, a figure in which thelogical architecture of the terminal, references 1′, is moreparticularly represented.

The terminal 1′in this case is a general type of terminal which may ormay not be secure, this characteristic being unimportant for explainingthe various types of communication in question.

As indicated above, the terminal 1′ naturally includes all the circuitsand devices required for its proper operation, which are not representedin order to simplify the drawing. Normally, the terminal 1′ is alsoconnected to standard peripherals, which may or may not be integrated,such as a display screen (not represented) and a keyboard 31, located ina secure enclosure (FIG. 1: 3) in the particular context of theinvention.

Normally, communications in networks take place in accordance withprotocols that comply with standards comprising several superposedsoftware layers. In the case of an internet network RI, communicationstake place in accordance with protocols that are specific to this typeof communication, but that also comprise several software layers. Thecommunication protocol is chosen based on the application specificallyenvisaged: web page consultation, file transfers, e-mail, forms or news,etc.

The architecture of communication networks is described by variouslayers. For example, the OSI (“Open Systems Interconnection”) standarddefined by the ISO includes seven layers, which run from the so-calledlower layers (for example the so-called “physical” layer that concernsthe physical transmission medium) to the so-called upper layers (forexample the so-called “application” layer), passing through intermediatelayers, including the so-called “transport” layer. A given layer offersservices to the layer that is immediately above it and requires otherservices from the layer that is immediately below it, via appropriateinterfaces. The layers communicate by means of primitives. They can alsocommunicate with layers on the same level. In certain architectures, oneor another of these layers may be nonexistent.

In an Internet environment, there are five layers, and more precisely,going from the top layer to the bottom layer: the applications layer(http, ftp, email, etc.), the transport layer (TCP), the network addresslayer (IP), the data link layer (PPP, Slip, etc.) and the physicallayer.

The terminal 1′ includes circuits 11 for accessing the internet network.This could be a modem for connecting to a switched telephone line or anintegrated services digital network (ISDN), for example via an Internetservice provider (or ISP). The circuits 11 for accessing the network RIcontain the lower software layers C₁ and C₂, which correspond to theaforementioned physical and data link layers.

Also represented are the upper layers C₃ and C₄, which correspond to the“network address” (IP) and “transport” (TCP) layers. The upperapplication layer (http, ftp, email, etc.) is represented schematicallyby a web browser NW of any type, preferably a standard type on themarket.

The interface between the lower layers C₁ and C₂ and the upper layers C₃and C₄ is constituted by a software layer 15, generally called a “lowerlevel driver.” The upper layers C₃ and C₄ are supported by thisinterface and are implemented by means of libraries of specificfunctions, or network libraries 14, with which they correspond. In thecase of the Internet, TCP/IP is implemented by means of libraries called“sockets.”

This organization allows the browser NW to present requests to a remoteserver 4, in order to consult web pages (HTTP protocol), transfer files(FTP protocol), or send email (email protocol).

The terminal 1′ also includes the card reader 30, located in a secureenclosure (FIG. 1: 3) in the particular context of the invention. Tocommunicate with the smart card 2, the card reader 30 also includes twolower layers CC₁ (physical layer) and CC₂ (data link layer), which playa role similar to the layers C₁ and C₂. The software interfaces with thelayers CC₁ and CC₂ are described, for example, by the PC/SCspecification (“Part 6, Service Provider”). The layers CC₁ and CC₂themselves are specifically described by the ISO standards 7816-1through 7816-4.

An additional software layer 13 forms an interface between applicationlayers, under the single reference Appli₁, and the lower layers CC₁ andCC₂. The chief function devolved to this layer 13 is amultiplexing/demultiplexing function.

On the smart card 2 end, there is a similar organization, i.e., thepresence of two lower layers, referenced CC′₁ (physical layer) and CC′₂(data link layer), as well as an interface layer 23, entirely similar tothe layer 13. This layer 23 provides an interface between theaforementioned protocol layers CC′₁ and CC′₂ and one or more applicationlayers, represented in the form of a single module referenced Appli₂.

Communications between the smart card reader 30 and the smart card 2take place by means of standard commands, known by the abbreviationAPDU, for “Application Protocol Data Unit”).

Various protocols can be used, including as non-exhaustive examples thefollowing:

the ETSI GSM 11.11 recommendation;

the protocol defined by the ISO 7816-3 standard, in character mode T=0;

the protocol defined by the ISO 7816-3 standard, in block mode T=1;

or the protocol defined by the ISO 3309 standard, in HDLC (forHigh-Level Data Link Control procedure) frame mode.

Within the scope of the invention, the ISO 7816-3 protocol is preferablyused, in block mode.

In an intrinsically known way, each protocol layer is associated with acertain number of primitives that allow data exchanges between layers ofthe same level and from one layer to another.

In the current state of the art, it is not possible to place the smartcard in direct communication with a remote server 4 via the Internet RI,since the communication protocol with a standard type of smart card 2,as indicated above, is incompatible with those used in the Internet orin any network of this type. Nor is it possible to establish directcommunications between the browser NW and the smart card 2, except byinstalling in the browser NW a piece of software, called a “plug-in,” ofa specific type.

Referring again to FIG. 1, assuming that the terminal 1 is linked to theInternet, and to summarize what has been mentioned above, it is notedthat this terminal 1 according to the prior art, comprising a secureenclosure 3 equipped with a keyboard 31 and a smart card 2 reader 30,includes two main communication interfaces, S₁ and S₂, represented indotted lines. A first interface S₁ links the enclosure 3 to the terminal1 per se in which the merchant application 10 is run, and a secondinterface S₂ is provided for communications with the smart card 2. Inreality, the interface S₂ is distributed between the application 300 andthe smart card 2. Added to both of these interfaces is the interface tothe outside (FIG. 2: particularly the circuits 11), which allows theterminal 1 to communicate with the internet network RI. The interface S₁accepts two levels of dialogue: a first, transparent dialogue for whicha command sent by the terminal 1 is executed without semanticmodification by the interface S₂, and a second level of dialogue thatinvolves the application 300.

Thus, the authentication by entering a password on the keyboard 31 is acommand submitted to the interface S₁ that is interpreted by theapplication 300 and transformed into a series of exchanges via theinterface S₂ between the application 300 and the smart card 2. Theresult of these exchanges is transmitted to the interface S₁.

Other than the fact that it is impossible, in the current state of theart, for a standard smart card 2 to accept direct exchanges with theInternet RI, as indicated above, the major drawback of the terminalsaccording to the prior art is constituted by the presence of theresident application 300. It is most often a so-called “proprietary”application, which means that the merchant application 10 must bewritten based on the characteristics and the type of the terminal used.It is therefore a priori different from one type of terminal to another,which does not facilitate maintenance operations. Moreover, it is notadapted to an Internet type of environment.

Standards have been proposed for applications of the same type as theinvention, such as the standard known by the abbreviation OCF (for “OpenCard Framework”), which attempts to standardize exchanges between themerchant terminal 1 and the smart card 2 reader 30 in compliance with,for example, the EMV standard for terminals. However, such a standard isnot directly usable in an internet context.

There is also the so-called “C-SET” protocol, known in the field ofbanking applications defined by the GIE bank card. Using this protocol,a user connects to a merchant site available on the web and makes apurchase. During the transaction, the latter accesses elements of thesecure enclosure in order to authenticate the holder of the bank cardmaking the purchase. This authentication is performed by runningsoftware in the terminal (non-secure part) and the enclosure.

This protocol is not free of drawbacks, either:

it requires the presence of specific software in the terminal and in theenclosure;

it requires the certification of the software required by C-SET;

the C-SET protocol is payment-oriented only; the software in theterminal that processes the information from the web server and from thebank card payment is payment software.

In these characteristics, it does not differ much from the solutions ofthe prior art mentioned above. It does not allow end-to-endcommunications using an Internet protocol, including direct addressingof the smart card. Given its specificity, it offers no flexibility andis not adapted for use in other fields: health care, updating of datastored in a smart card, point crediting, etc

SUMMARY OF THE INVENTION

While eliminating the drawbacks of the methods and architectures of theprior art, some of which have been mentioned, the object of theinvention is to fulfill the needs that have arisen.

It promotes the utilization in the Internet of terminals comprising asecure enclosure equipped with at least a smart card reader and akeyboard, by allowing the migration of applications from smart cardreaders and terminals to a remote web server, and direct dialogue withthe smart card.

It allows an updating or an addition of software in the secureenclosure, with maximum security.

To achieve this, according to a first aspect of the invention, the smartcard is not addressed in standard fashion by APDUs in accordance withthe aforementioned ISO 7816 communication protocol, but by using a URLaddress (for “Universal Resource Locator”). As is known, a URL addressis constituted by an IP address per se and a port number. In the sameway, the secure enclosure uses this URL addressing.

According to one aspect of the invention, the smart card also acts likea web server and/or client.

The secure enclosure according to the invention is “transparent” for theinternet network, in the sense that the “card commands” emanating fromthe remote merchant server do not involve elements for addressing theterminal. It follows that the resources associated with the secureenclosure are not accessible from the internet network. On the otherhand, the applications contained in the smart card have the capabilityto address and activate all the computing resources present in thesecure enclosure, including a keyboard, by simply using URL addressing,as will be explained below.

To achieve this, the terminal physically comprises:

a secure enclosure of a modified type, comprising at least a card readerand a keyboard (and/or another computing resource), both of which arelinked to a so-called secure-enclosure HTTP server, as well as anexecution unit that manages all of the resources present in theenclosure; and

in addition to the standard elements (memories, etc.) and a web browser,a first, so-called terminal communication node, which handlescommunications between the internet network, the web browser and/or thesecure enclosure.

Furthermore, the aforementioned secure enclosure comprises a second,so-called enclosure communication node, which handles communicationsbetween the terminal itself, via the first communication node, theso-called secure-enclosure HTTP server, and/or the smart card reader.

The smart card itself is equipped with a third, so-called cardcommunication node, and a software adaptation that acts like an HTTPserver, forming an interface between at least one application residentin the smart card and the second communication node.

The first communication mode routes the requests from the internetnetwork having a port number associated with the secure enclosure tothis enclosure and performs the necessary protocol adaptations forplacing the internet network in direct communication with the secondcommunication node, and handles the propagation of information and/ororders to the smart card.

For certain applications, especially applications requiring a high levelof security, the secure enclosure can advantageously comprise one ormore additional computing resource(s), such as for example devices forbiometric authentication (ocular recognition, voice and/or signaturerecognition), a coprocessor, or an external interpreter.

In a preferred variant of the method according to the invention, theprograms required to run the elements and resources of the secureenclosure, or to update them, are downloaded via the internet networkfrom a remote web server linked to this network. The update may includeat least the partial erasure of these programs.

It is also possible, in additional variants of embodiment, to download,update and/or delete applications or parts of applications stored in thesmart card (files, programs, scripts, etc.) via the internet network andthe communication modes.

All of these operations can be performed under very good securityconditions, due to the aforementioned transparency of the secureenclosure relative to the internet network.

Hence, the main object of the invention is a terminal equipped with asecure enclosure designed to communicate with at least one web servervia an internet network, using a first Internet communication protocol,said secure enclosure comprising at least one smart card reader, saidsmart card storing at least one software application, characterized inthat said terminal comprises a non-secure part comprising at least afirst module called a first communication mode, said secure enclosurecomprises at least a second module called a second communication nodeand said smart card comprises at least a third module called a thirdcommunication node, in that said communication nodes comprise,respectively, first, second and third protocol stacks, each comprising agiven number of so-called standard software communication layers, andrespectively, first, second and third pieces of specific software, eachcomprising at least one first software entity, said first softwareentities being paired two by two, in that said first node authorizes atleast communications between said terminal and said web server, usingsaid first Internet communication protocol, in that said first entitiesof said first and second pieces of specific software authorize theestablishment of a bilateral data exchange session between said terminaland said secure enclosure, using a second given communication protocol,in that said first entities of said second and third pieces of specificsoftware authorize at least the establishment of a bilateral dataexchange session between said secure enclosure and said smart card, viasaid smart card reader, using a third given communication protocol, soas to be able to connect at least one of said software applications ofthe smart card with said web server.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be described in greater detail by referring tothe attached drawings, in which:

FIG. 1 schematically illustrates an example of a terminal according tothe prior art comprising a secure enclosure equipped with a smart cardreader and a keyboard;

FIG. 2 illustrates, in a general way, the logical architecture of aterminal according to the prior art comprising a smart card reader andcommunicating with a web server via the internet network;

FIG. 3 schematically illustrates an exemplary general architectureaccording to the invention allowing communications, via the internetnetwork, between a remote so-called merchant server and a terminalequipped with a secure enclosure comprising a smart card reader, akeyboard and other computing resources;

FIG. 4 illustrates the logical architecture of modules allowingcommunications between the secure enclosure of the terminal of FIG. 3and the smart card; and

FIG. 5 illustrates a particular embodiment of the logical architectureof the smart card.

DESCRIPTION OF THE PREFERRED EMBODIMENT(S)

We will now describe an exemplary embodiment of a terminal with a secureenclosure according to the invention and the system architecture forcommunication between this terminal and a so-called “merchant” server,with reference to FIG. 3.

The terminal, hereinafter referenced 5, can basically be embodied, ashas been indicated, by a microcomputer or a similar device. It comprisesa certain number of standard elements: microprocessor, RAM and ROM, massstorage (hard disk, etc.), etc., which are not represented and are wellknown to one skilled in the art. On the other hand, in the applicationspecific to the invention, the terminal 5 comprises an enclosure 6,secured by physical and logical means that are intrinsically known. Thissecure enclosure 6 comprises elements common to the prior art, but alsoelements specific to the invention that will be indicated below. Tobegin with, it comprises, as in the prior art, a keyboard 62, its driveror “handler” 620, and a smart card reader 7.

The terminal 5 is connected to a remote server 4 via the Internet RI orany other network of this type (intranet, extranet). As in the case ofFIG. 2, it comprises all of the software and hardware elements that makeit possible to communicate using one of the protocols used on theInternet, including the HTTP/TCP-IP protocol. It is thereforeunnecessary to describe these elements, except to mention that itincludes a web browser, referenced 51. This browser 51 makes itpossible, in particular, to present requests to the server 4. Itconstitutes one of the applications present in the terminal 5, which canactually include a plurality of applications.

According to a first characteristic of the invention, the applicationsspecific to the merchant application have migrated to the server 4. Thelatter therefore specifically comprises an HTTP server per se 40 and theaforementioned merchant applications, stored in storage means 41.

According to another characteristic of the invention, the terminalcomprises a first specific module 50, which will be called the firstcommunication node, or “terminal communication node.” This module 50comprises standard communication means, including the protocol stacksdescribed in connection with FIG. 2, but also specific elements thatwill be described below.

According to yet another characteristic, the secure enclosure 6 alsocomprises a specific module 50, which will be called the secondcommunication node or “enclosure communication node.”

The first communication node 50 makes it possible to make the servers ofthe network RI, for example the server 4, as well as the applicationspresent in the non-secure part of the terminal 5 (for example the webbrowser 51) communicate with the elements present in the secureenclosure 6, including the smart card reader 7 and the smart card 8, viathe second communication node 60.

The secure enclosure 6 comprises an HTTP server 61, which will be calledthe “enclosure HTTP server,” disposed between the second communicationnode 60 and the keyboard 62. The latter constitutes one of the computingresources of the secure enclosure 6. The latter, as indicated in thepreamble of the present specification, can comprise additional resources1 through i, represented by the single reference number 63. These caninclude, for example, biometric authentication devices, a coprocessor oran external interpreter. The resource(s) 63 is (are) also connected tothe HTTP server 61, in a way similar to the keyboard 62.

The server HTTP 61 is also connected to the smart card reader 7.

The communication node 60 makes it possible to route the requests fromthe terminal 5 to the smart card 8, via the smart card reader 7, and toroute, in the opposite direction, the requests from the smart card 8,either to the HTTP server 61 or to the terminal 5, via the communicationnode 50.

According to one aspect of the invention, the HTTP server 61 allows thesmart card 8, and it alone, to use the resources 62 through 63 of thesecure enclosure 6.

The impossibility of accessing the information in the keyboard 62 or inthe other resources 63, except than by passing through the smart card 8,which plays an intermediary role, is due to several factors:

a/ the enclosure 6 is physically secure (it is physically impossible to“spy” on the elements);

b/ the programming of the node 60 is such that it prevents any routingof data originating from outside the enclosure HTTP entity 61, the node60 also being protected, since it is located inside the secure enclosure6; and

c/ the programming of the enclosure HTTP entity 61 is such that thelatter does not accept requests other than those emanating from thesmart card 8, this server 61 also being protected, since it is alsolocated inside the secure enclosure 6.

While point a/ itself is common to the prior art and to the invention,points b/ and c/ constitute specific and advantageous characteristics ofthe invention.

We will now describe in greater detail how communications take placebetween the internet network RI and the elements of the non-secure partof the terminal 5, between the latter and those of the secure terminal6, between the elements of the secure terminal 6, and between the latterand the smart card 8 via the smart card reader 7.

According to one of the main characteristics of the invention, all ofthese communications take place in a mode that will be qualified as“homogeneous,” entirely compatible with Internet protocols, using astandard URL address, and retaining the standardized communicationprotocols, particularly between the smart card 8 and the smart cardreader 7 (i.e. in compliance with the aforementioned ISO 7816standards).

The communications between the web browser 41 and the “merchant” server4 do not pose any particular problems and can take place normally inaccordance with the HTTP protocol, using standard protocol layers (seeFIG. 2), and URL addressing. On the other hand, as has been mentioned,in the prior art, this is not true between the non-secure and secureelements of a terminal (FIG. 1: 1), in which communications normallytake place in RS232 mode, or between the elements of the secureenclosure 6 and the smart card 8 via the reader 7. In the latter case,as explained in connection with FIG. 2, the communications do take placeby implementing protocol layers, but with the help of a set of APDUorders, in compliance with the aforementioned ISO 7816-3 standard, hencein a way that is incompatible with an Internet protocol.

Also, the invention offers specific provisions that make it possible tounify the communications, while retaining the standardization of theelements involved in the communications and resulting in only minormodifications.

First of all, we will describe in detail the modifications to be made tothe secure enclosure 6 and the smart card 8, so as to be able to handlecommunications between these two entities in a manner according to theinvention.

According to one characteristic of the invention, the smart card 8 isequipped with a specific module constituting a third communication node80 and an HTTP server 81, which will hereinafter be called the “cardcommunication node” and the “card HTTP server,” respectively. The napplication(s) present in the smart card 8, A₁ through A_(n), areconnected through a first side of the HTTP server 81. With theseprovisions, the smart card 8 is transformed into a web server and/orclient for the secure enclosure 6 and can be “addressed” by a URLaddress.

This architecture is essentially obtained, according to the invention,by installing a first specific communication protocol layer into thesmart card 8. Likewise, a second specific communication protocol layer,forming the match of the first, is installed in the secure enclosure 6.

For the exchanges between the smart card 8 and the secure enclosure 6,the block diagram of FIG. 3 can be represented by the logicalarchitecture illustrated by FIG. 4.

In this architecture, we find the protocol layers of the prior art, asillustrated by FIG. 2, which play the same roles and have the samereferences. It is therefore unnecessary to describe them again.

On the other hand, on either end, i.e., in the secure enclosure 6 and inthe smart card 8, two additional specific protocol layers are provided,respectively 64 and 84.

In the secure enclosure 6, the specific layer 64 is interfaced with theprotocol layers of the card reader 3, i.e., the lower layers CC₁ andCC₂, via the multiplexing layer 13. The specific layer 64 allows thetransfer of data packets to and from the smart card 8. In addition, itadapts the existing applications for utilizations involving the smartcard 8, without having to rewrite them.

On the smart card 8 end, there is an entirely similar organization,constituted by an additional instance of the specific layer, referenced84, the match of the layer 64.

More precisely, the specific layers 64 and 84 are subdivided into threemain software elements:

a module, 640 or 840, for transferring blocks of information between thelayers 13 and 23, via the conventional layers CC₁, CC₂, CC′₁, and CC′₂.;

one of more pieces of software called “intelligent agents,” 641 or 841,which perform, for example, protocol conversion functions;

and a module for managing the specific configuration, 642 and 842respectively, a module that is comparable to a particular intelligentagent.

Therefore, in the secure enclosure 6 and the smart card 8, there is acommunication protocol stack between the two entities.

The level-two entities (data link layers) CC₂ and CC′₂ handle theexchanges between the smart card 8 and the secure enclosure 6. Theselayers are responsible for detecting, and possibly correcting,transmission errors. The various protocols mentioned are usable for thispurpose (the ETSI GSM 11.11 recommendation; the protocol defined by theISO 7816-3 standard, in character mode T=0 or in block mode T=1; or theprotocol defined by the ISO 3309 standard, in HDLC frame mode). Asindicated, within the context of the invention, the ISO 7816-3 protocol,in block mode, is preferably used.

In an intrinsically known way, each protocol layer is associated with acertain number of primitives that allow data exchanges between layers ofthe same level and from one layer to another. For example, theprimitives associated with the level-two layer are of the data request(“Data.request”) type and data response by the card (“Data.response”)type, as well as the data confirmation (“Data.confirm”) type.

More particularly, the specific layers 64 and 84 are responsible for thedialogue between the smart card 8 and the host, i.e., the secureenclosure 6. They also allow the establishment of a configurationadapted to the sending and/or reception of data packets.

As indicated above, the layers comprise three distinct entities.

The first entity, the module 640 or 840, is essentially constituted by asoftware multiplexer. It allows the exchange of information between thesmart card 8 and the host terminal 6, in the form of protocol dataunits. It plays a role similar to that of a data packet switcher. Theseunits are sent or received via the level-2 layer (data link layer). Thisparticular communication protocol makes it possible to place at leastone pair of “intelligent agents” in communication. The first agent ofeach pair, 641, is located in the layer 64 on the secure enclosure 6end; the second, 841, is located in the layer 84, on the smart card 8end. A link between two “intelligent agents” is associated with asession. A session is a two-way data exchange between these two agents.

An intelligent agent can perform all or some of the functions of thelevel three and four layers, depending on the configuration implementedby the secure enclosure 6.

A particular intelligent agent is advantageously identified by a wholenumber, for example in 16 bits (a number between 0 and 6535). Thisidentifier is used, for example, in a protocol data unit constituting adestination reference and a source reference.

There are two main categories of intelligent agents: agents of the“server” type, which are identified by a fixed reference, and agents ofthe “client” type, which are identified by a variable reference,delivered by the configuration management module 642 or 842.

The process for opening a session is normally the following: anintelligent agent of the “client” type opens the session with anintelligent agent of the “server” type. The modules 642 and 842 managetables (not represented) which contain a list of the intelligent agentspresent, on the host 6 end and smart card 8 end.

The intelligent agents, 641 or 841, are associated with particularproperties or attributes. To illustrate the concept, and to give anon-limiting example, the following four properties are associated withintelligent agents:

-   -   “host”: agent located in the secure enclosure;    -   “card”: agent located in the smart card;    -   “client”: agent that initializes a session;    -   “server”: agent that receives a session request.

The intelligent agents make it possible to exchange data.

The configuration management modules, 642 and 842, respectively, arecomparable, as has been indicated, to particular intelligent agents. Forexample, the module 642 on the host 6 side, specifically managesinformation related to the configuration of the secure enclosure 6(operating modes), a list of the other agents present, etc. The module,842, on the smart card 8 side, has similar functions. These two agentscan be placed in communication with one another to establish a session.

According to one characteristic of the invention, the smart card 8offers the host system, i.e. the enclosure 6, a virtual terminal model.To do this, the smart card 8 acts like a web server and/or client.

In a practical way, the smart card 8 is advantageously “addressed” usinga URL address that defines a loopback to the terminal 5, and moreparticularly to the secure enclosure 6, and not a pointing to anexternal server like the server 4. For example, the structure of thisURL is normally the following:

-   -   http://127.0.0.1:8080 (1) or    -   http://localhost:8080 (1a)        in which 127.0.0.1 is the IP loopback address (“localhost” being        the literal translation of 127.0.0.1) and 8080 is the port        number. The URL address of the resources 62 and/or 63 could be        completed by a suffix of the “/xxx” type. For example, the        management module 620 of the keyboard 62 could have the        following as its URL address:    -   http://localhost:8080/kb (2)

The logical architecture that allows communications between the terminal5 per se (between the nodes 50 and 60), i.e. the non-secure elements ofthe latter, and the secure enclosure 6 is similar to that represented inFIG. 4. Consequently, sessions can be established between thecommunication nodes 50 and 60 in accordance with the general schema thathas just been described. The secure enclosure can particularly beaddressed by a URL address, under the same port number as the smartcard, or 8080 in the example described.

The communication node 50 also allows the terminal 5 to communicate withthe internet network RI. Also, in addition to the properties associatedwith the intelligent agents, which are listed above, there are also thefollowing two properties:

-   -   “local”: agent that does not communicate with the network;    -   “network”: agent that communicates with the network.

The terminal 5, in its entirety, is addressed by the same IP address asabove. It hosts at least one so-called terminal application,advantageously the web browser 51. The latter is associated with aparticular port.

For example, using a web page technique and hyperlinks, a user (notrepresented) can choose a product or a service from those available andtransmit the request to the merchant server 4.

In addition to the web client-server function offered by the smart card8, according to another aspect of the invention, included in the latterthere is a mechanism similar to the so-called CGI (for “Common GatewayInterface”) function installed in conventional web servers.

Before describing an exemplary architecture according to the inventionthat makes it possible to perform a function of this type, even in thesmart card 8, it is useful to review the chief characteristics of a CGIoperating mode.

CGI is a specification for implementing, from a web server, applicationswritten for the UNIX (registered trademark), DOS or WINDOWS (registeredtrademark) operating systems. By way of example, for the UNIX operatingsystem, the specification is CGI 1.1 and for the Windows 95 operatingsystem, the specification is CGI 1.3.

Again by way of example, an HTTP request for a URL address of the type

-   -   “http://www.host.com/cgi-bin/xxx” (3),        in which “host” refers to a host system (generally remote), is        interpreted by a web server as the execution of a CGI-type        command script named “xxx” and present in the directory        “cgi-bin” of this host system. Although the directory can have        any name a priori, by convention, this is the name given to the        directory that stores scripts of the CGI type. A script is an        instruction set of the operating system of the host system,        whose final result is transmitted to the web browser that sent        the aforementioned request or to any other application accessing        the service, such as a merchant server. Various languages can be        used to write this script, for example the language PERL        (registered trademark).

In a practical way, the request is normally displayed on a computerscreen in the form of a form contained in an HTML page. The languageHTML makes it possible to post a form at a URL address. The formincludes one or more fields, which may or may not be required, and whichare filled in by a user using the usual entry means: a keyboard fortext, a mouse for boxes to be checked or so-called “radio” buttons, etc.The contents of the form (and possibly so-called “hidden” informationand instructions) is addressed to the web server. The HTML code of thepage describes the physical structure of the form (frame, graphics,color and any other attribute), as well as the structure of the datafields to be filled in (name, length, data type, etc.).

The transmission can take place in two main types of HTTP formats. Afirst format uses the so-called “POST” method, and a second uses theso-called “GET” method. A piece of format type information is present inthe code of the form page.

This mechanism, however, is not directly transposable to a smart card,even though the latter offers the web server functionality according toone of the characteristics of the invention.

We will now describe an exemplary architecture that makes it possible toactivate any conventional type of application via a web server in thesmart card, with reference to FIG. 5.

A merchant server 4 activates an HTTP request of the GET type at a URLaddress, which can be presented in the following way:

-   -   “http://@card:8080/xxx.8080/cgi-bin/le_cgi ? param1+param2” (4),        in which “@card” is the IP address of the terminal supporting        the smart card (for example the loopback address “127.0.0.1” of        the relation (1)), “le_cgi” is a particular CGI script to be        executed in the smart card 8 and “param1” and “param2” are        parameters to be entered into the aforementioned script. The        request is first transmitted to the secure enclosure 6, via the        communication nodes 50 and 60 (FIG. 3).

A session is established between the terminal and the smart card reader.Then another session is established between a pair of intelligentagents, 641 and 841, located in the specific layers of the secureenclosure 6 and the smart card 8, respectively 64 and 84. The data thenpasses through the packet multiplexer 640 of the specific communicationprotocol layer 64. It then passes through the standard protocol layers(see FIG. 2). However, in order to better illustrate certain specificaspects of the invention, which will be explained below, these layersare divided into two parts in FIG. 5: an APDU command handler 65 a andlower protocol layers 65 b(ISO 7816-3 standard).

Likewise, in the smart card 8, it passes through the lower protocollayers, referenced 85 b, and the APDU command handler on the card end,referenced 85 a, then the packet multiplexer 840, in order to bereceived by the intelligent agent 841, which will be called a “webagent.”

It is appropriate to note that the data addressed to the web agent 841are transported, in an intrinsically conventional way, in the form ofAPDU commands designed for the particular “packet multiplexer”application 840. The APDU command handler 85 a selects this applicationin a way that is entirely similar to the other applications present inthe smart card 8, A₁ through A_(n). In other words, the packetmultiplexer 840 is seen by the APDU command handler 85 a as an ordinarycard application.

The HTTP request is then analyzed by the web agent 841, which detects areference to a particular directory, which will hereinafter be called“cgi-smart” by convention, and to a particular application, for exampleA_(i). The complete path in this case is therefore “cgi-smart/A_(i)”.

According to one characteristic of the method of the invention, theabove entity designates a particular script associated with an equallyparticular application.

According to another aspect of the invention, particular intelligentagents are installed in the smart card 8, which will hereinafter becalled “script translating agents,” or in abbreviated fashion, “ATS.”The script is then interpreted by one of the intelligent agents. Thistranslation can be performed in various ways:

a/ by the web agent 841 itself, which in this case is equipped with adual capacity;

b/ by a single script agent capable of translating all of the scriptspresent in the smart card 8;

c/ by a dedicated script agent which will hereinafter be called “ATSD”(one per script); or

d/ by an APDU agent 850 a of the APDU command handler 85 a, which inthis case is equipped with a dual capacity.

The APDU agent 850 a is a component of the APDU command handler layer 85a. The latter is a layer capable of centralizing all of the APDUcommands sent and/or received by the system, of selecting applicationsfrom A₁ through A_(n), but also of offering an intelligent agent typeinterface. It is therefore capable, according to one of thecharacteristics of the invention, of communicating with all of theintelligent agents (via sessions), whether these agents are located inthe enclosure 6 or the smart card 8.

In case c/ above, a session is opened between the web agent 841 and oneof the agents ATSD.

FIG. 5 illustrates an exemplary architecture for which the translatingagents are of the “ATSD” type. They are referenced ATS₁ through ATS_(n),and associated with the applications A₁ through A_(n). The selectedapplication being assumed to be the application A_(i), the session isestablished between the web agent 841 and the agent ATS_(i).

A script translating agent generates a set of APDU commands. A sessionis opened between the translating agent, for example the agent ATS_(i),and the APDU agent 850 a. The orders are then sent to the APDU agent 850a. The APDU command handler 85 a selects the “CGI” application A_(i) andtransmits to it the APDU commands, commands which are translated andtherefore conventional, and which it is capable of understanding.

The responses from the application A_(i) are transmitted to the APDUcommand handler 85 a, to the APDU agent 850 a, then again to the agentATS_(i) (and more generally to the script translating agent).

The various routings are represented symbolically in FIG. 5 by solidlines connecting the functional blocks, or by dotted lines inside theseblocks.

To illustrate the concepts, without in any way limiting the scope of thepresent invention, the addressing technique having been defined ingeneral terms up to this point, we will now describe in detail variouspossible routings, which will be called cases of utilization and whichwill be referenced CU-n:

CU-1: communication between the merchant server 4 and the smart card 8.

To achieve this, a URL address according to (1) is used. In this case,it is not necessary to use the keyboard 62. The request, transmitted viathe internet network RI, arrives in the communication node 50. Thelatter identifies the port associated with the smart card, i.e. the port8080, which is the same as that of the secure enclosure 6. Thecommunication node 50 routes the request to the communication node 60.In all cases, no matter what the URL address, the latter routes the datapackets received to the smart card 80. Finally, the latter activates oneof the applications of the smart card 8, for example the application A₁.

CU-2: communication between two applications of the smart card 8.

For example, the application A₁ wants to communicate with theapplication A_(n). The request emanating from the application A₁ isrouted through the HTTP server 81. In a practical way, a session isestablished between a pair of local intelligent agents in the smart card8, in accordance with the schema described in connection with FIG. 4.The communication node 80 is not involved. There is no communicationprotocol adaptation to be performed.

CU-3: communication between a card application and the merchantapplication 41 in the server 4.

This case can occur especially when the smart card 8 has received arequest from the merchant server 4 (case CU-1). A local application inthe smart card 8, for example the application A₁, can be activated. Agiven action, initiated by the received request, is then performed inthe smart card, for example a CGI-type action, by running a script orany equivalent process. This action is performed under the control ofscript-translating intelligent agents, as explained in connection withFIG. 5.

As a result, the application A₁ presents a request addressed to theserver 4. After examining the IP address, the HTTP server 81 routes therequest to the communication node 80. A session is established betweenthe smart card 8 and the secure enclosure 6, more precisely between thecommunication nodes 60 and 80, in accordance with the schema describedin connection with FIG. 4. Likewise, the communication node 60, afterexamining the IP address, transmits the request to the communicationnode 50. The latter, after examining the IP address, in turn transmitsthe request via the internet network RI to its final destination, i.e.to the server 4.

The process can include several passes back and forth between the smartcard 8 and the server 4, during the time of one transaction. When theprocess is finished (at the end of the CGI for example), the responsefrom the smart card is transmitted to the merchant server 4,particularly via the successive communication nodes 80, 60 and 50.

CU-4: communication between a “card application” and a “terminalapplication.”

For example, the application A₁ wants to communicate with a printmanager (not represented) of the terminal and presents a request in thisdirection. After examining the IP address and the port number, the HTTPserver 81 routes the request to the communication node 80. The requestthen follows the same path as in case CU-3, until it reaches thecommunication node 50. The latter, after examining the IP address andthe port number, routes the request to the terminal applicationaddressed, for example the print manager.

CU-5: communication between a “card application” and a resource of thesecure enclosure.

It is assumed, first of all, in this case of utilization, that the smartcard 8 is in “slave” mode relative to the merchant server 4 and that thelatter has sent a request addressed to the smart card 8. This request isprocessed in the manner explained in cases CU-1 and CU-3. For example, a“merchant CGI” is executed in the smart card 8, in the manner describedin connection with FIG. 5. This script is executed by activating one ofthe applications, for example A_(i), with the help of one of the scripttranslating agents, for example ATS_(i). It is assumed that the merchantCGI needs information entered on the keyboard 62 (a password forexample) or other authentication information (from a biometric deviceconstituting one of the resources 63). The CGI in question must beexecuted with a particular URL address. The application A_(i) sends arequest whose address is, for example, the one given by (2) above. Thepresence of the suffix “/kb” tells the communication node 60 that it isnecessary to loop the request back to the HTTP server 61, which in turnactivates the driver 620 of the keyboard 62, and retrieves the awaitedinformation (the entry of a password for example). The response to therequest is transmitted, via the same path but in the opposite direction,to the smart card 8.

The response to the request from the merchant server 4 is thentransmitted back to the latter. A back-and-forth dialogue can beestablished in a manner similar to case CU-3.

Several CGIs can be executed during the time of one transaction.

To illustrate the concepts, a first “merchant CGI” can result in thedisplay, on a screen included in the secure enclosure 6 (one of theresources represented under the single reference 63), of a messageprompting a user to compose a code and displaying an amount. A secondCGI reads, for example, information transmitted by the keyboard 62. Athird CGI can result, in this same display device, in a message of the“CODE CORRECT” type or any similar message.

CU-6: communication between the terminal and one of the resources of thesecure enclosure.

For example, an application of the terminal 5 (in its non-secure part),for example the web browser 51, wants to communicate with one of theprotected resources, for example with the keyboard 62, and sends arequest in this direction. The communication node 50 examines the URLaddress, identifies the port number of the secure enclosure 6 andtransmits the request to it. The communication node 60, as a result ofits programming, systematically routes the requests received, even ifthey are addressed to one of the resources inside the secure enclosure6, to the smart card 8. A this stage, the request follows a path similarto case CU-1. It is the smart card 8 that determines whether there is aneed to retransmit the request to the secure resource initiallyaddressed, and possibly to modify it. The decision can result from anidentification procedure involving the examination of security datastored in the smart card, particularly in a read-only memory, possiblyin encrypted form. As in case CU-4, an element outside the secureenclosure 6 never has direct access to the protected resources.

This last characteristic allows updates of software resident in thesecure enclosure 6, additions or at least partial deletions of thissoftware, in a way that is more reliable than in the prior art. In fact,it is customary to authenticate modifications of this nature from a keyembedded in the software of the secure enclosure 6.

Since only the smart card 8 can access the protected resources of thesecure enclosure 6 from the outside, the downloading of softwareresources can therefore be done from an Internet server, by means of thesmart card, while retaining a high degree of security. The downloadeddata, if they are sensitive, need only be suitably encrypted, using arobust algorithm and/or a long enough encryption key. As a result of theintermediary function played by the smart card 8, the mechanismimplemented in the invention is a priori stronger than a simpleembedding of a key in a storage device (not represented) of the secureenclosure 6.

It is also possible to modify the contents of the software resources ofthe secure enclosure 6 directly from a smart card 8, by downloadingpieces of software stored in the latter. The volume of software thusdownloaded is nevertheless limited by the resources specific to thesmart card (storage capacity), which is not a priori the case with adownload via an internet network from a web server, which server can beequipped with substantial computing resources. The download time isnaturally dependent on the quantity of software to be downloaded, butthe use of fast modems and/or high-speed communication lines tends tokeep this time within limits that are entirely reasonable for theapplications envisaged.

With the reading of the above, it is easy to see that the inventionclearly achieves the objects set forth.

While maintaining the possibility of using conventional components andstandardized communication modes, particularly between the secureenclosure and the smart card, via the reader, it specifically allowsaddressing and communications that are compatible with the HTTP internetprotocol. It transforms the smart card into a web client-server, capableof performing operations of the CGI type. It specifically allows adirect and interactive addressing of the smart card from a web servervia the internet network, or in the opposite direction. It does notrequire any specific merchant application in the terminal itself and inthe secure enclosure. It offers a great deal of flexibility and iseasily adapted to various fields of application. It involves only minormodifications of the components used, which modifications canessentially be summarized as the installation of specific pieces ofsoftware, it being understood that the word “specific” does not indicateany dependency on the applications handled. In particular, theapplications resident in the smart card are standard applications and donot require any rewriting. Moreover, the specific applications, from a“merchant application” point of view, are located entirely in the remoteweb server. The latter can contain a plurality of them. Because of this,it is easy to update and delete these applications, as well to add newapplications. This characteristic offers great flexibility. The versionof the programs is identical for all of the terminals that connect tothe server. Finally, the security provided by the invention is veryhigh. It is possible to use robust encryption algorithms and very longkeys for communications through the internet network. Furthermore,according to one characteristic of the invention, all the requestsoriginating from outside the secure enclosure, whether from thenon-secure part of the terminal or directly from the Internet, mustnecessarily pass through the smart card and remain under its exclusivecontrol. The latter alone decides, for example based on residentsecurity data, what use should be made of these requests. And the smartcard remains the property of the holder.

It should be clear, however, that the invention is not limited to justthe exemplary embodiments explicitly described, particularly in relationto FIGS. 3 through 5.

In one embodiment (not represented), the secure enclosure could containonly a smart card reader, the application(s) stored in the smart cardbeing self-sufficient in authenticating the holder and/or allowing atransaction between the remote web server and the smart card. Thekeyboard could be omitted and replaced by one of the protectedresources, such as a biometric device. Finally, it is possible to add,to the first smart card reader, a second smart card reader, or several.

While this invention has been described in conjunction with specificembodiments thereof, it is evident that many alternatives, modificationsand variations will be apparent to those skilled in the art.Accordingly, the preferred embodiments of the invention as set forthherein, are intended to be illustrative, not limiting. Various changesmay be made without departing from the true spirit and full scope of theinvention as set forth herein and defined in the claims.

1. An assembly comprising: a smart card and a terminal designed tocommunicate with at least one web server via an internet network, theterminal having a main part and a peripheral part, the peripheral partresiding in a tamper-resistant enclosure and including a smart cardreader for receiving the smart card, the main part of the terminalcomprising: a first module for enabling the terminal to communicate withthe web server by establishing a communication between said first moduleand the web server in accordance with an internet communication protocolvia two stacks of open-systems-interconnection layers specific to theinternet communication protocol, one of said two stacks residing in saidfirst module and the other stack residing in the web server; theperipheral part of the terminal further comprising: a second moduleconnected to the first module for establishing a communication betweenthe peripheral part and the main part in accordance with aperipheral-device-communication protocol via two stacks ofopen-systems-interconnection layers specific to theperipheral-device-communication protocol, one of said two stacksresiding in the second module and the other stack residing in said firstmodule; the smart card comprising: a smart card communication module forestablishing communication between the smart card and the peripheralpart in accordance with a smart card communication protocol via twostacks of open-system-interconnection layers specific to thesmart-card-communication protocol, one of said two stacks residing inthe smart card communication module and the other stack residing in saidsecond module, said smart card further comprising a card HTTP serverconnected via the smart card communication module to the second module;and wherein each of said two stacks of open-systems-interconnectionlayers specific to the peripheral-device-communication protocol and eachof said two stacks of open-systems-interconnection layers specific tothe smart card communication protocol are provided with a softwareelement called an intelligent agent having protocol conversion functionsso that an internet communication between an application residing on thesmart card activated through said card HTTP server, and an applicationresiding on the web server is established via the respective stacks ofopen-systems-interconnection layers provided with the respectiveintelligent-agents, a first intelligent agent being provided in saidperipheral part and using an interface connected to the smart cardreader so as to communicate with a second intelligent agent provided insaid smart card, said first and second intelligent agents enabling abilateral data exchange session between said second module and smartcard communication module.
 2. The assembly of claim 1, wherein said mainpart comprises a web browser, said internet communication protocol forcommunication between the main part and the web server including theHTTP/TCP-IP protocol with URL addressing, comprising an IP internetaddress element and a port number for the selection of said terminal andof an internal element of said terminal.
 3. The assembly of claim 1,wherein said peripheral part also comprises at least one data entrykeyboard and at least one enclosure HTTP server disposed between saidkeyboard and said second module.
 4. The assembly of claim 3, whereinsaid peripheral part comprises at least one additional computingresource connected to said HTTP server.
 5. The assembly of claim 4,wherein said additional computing resource is a biometric authenticationdevice.
 6. The assembly of claim 3, wherein said smart card includesmeans for storing several software applications and also comprises acard HTTP server disposed between said storing means and said smart cardcommunication module, said card HTTP server being adapted forselectively activating at least one of said software applications uponreception of a request coming from said second module and transmittingrequests sent by said applications to said smart card communicationmodule.
 7. The assembly of claim 6, wherein said smart card alsocomprises a software entity capable of interpreting an instruction setconveyed by said data received from said smart card communicationmodule, and of translating the instruction set into a set of commands,said translated commands set being associated with one of said softwareapplications to be activated in said smart card.
 8. The assembly ofclaim 6, wherein said web server stores a merchant software applicationdesigned to be placed in interactive communication with at least one ofsaid software applications of said smart card via said first, second andsmart card communication modules.